The :is() and :where() pseudo-classes allow you to group multiple selectors and apply styles efficiently, but they differ in how they contribute to specificity.

Key Differences in Specificity

1
:is(selector-list) – The specificity of :is() is equal to the most specific selector inside the list. This means it can override less specific rules.
2
:where(selector-list) – The specificity of :where() is always zero, regardless of the selectors inside it. This makes it ideal for utility or default styles that should not override other rules.
3
Both simplify writing complex selectors, but :where() avoids specificity conflicts while :is() preserves them.

Example: :is() vs :where() Specificity

In this example, the headings get dark blue because :is() preserves specificity. The regular paragraph gets gray from :where(), but the .special paragraph overrides it with black because :where() has zero specificity.

Best Practices

1
Use :is() when you want grouped selectors to maintain specificity and possibly override other rules.
2
Use :where() for default or fallback styles that should not interfere with more specific rules.
3
Combine them with other pseudo-classes for precise and readable CSS.
4
Test across browsers, as support for :is() and :where() is broad in modern browsers but may require fallback for older ones.

Difficulty: 6/10

Topics: specificity, selector matching, CSS specificity inheritance

Scenario Questions

0-2 years experience

1
You have a button with a class .primary and you're trying to style it with :is(.primary, .accent) — but your styles aren't taking effect. Why might that be?
2
If you write :where(.header, .nav) { color: blue; } and .header { color: red; }, what color will the header text be? Why?
3
You're using :is() to group selectors for a form input, but it's being overridden by a more specific rule. How would you fix it?

2-5 years experience

1
A designer says the theme colors aren't applying consistently across components — you notice they're using :where() for global resets but some components still override them. What’s likely happening and how would you fix it?
2
Your team’s CSS library uses :is() for utility classes, but now some custom component styles are breaking because of specificity conflicts. How would you diagnose and resolve this?
3
You’re debugging a layout where a :where() rule isn’t overriding a hardcoded inline style — why is that, and what’s your next step?

5-8 years experience

1
You're designing a design system where global resets need to be non-intrusive but still allow component-level overrides. Would you use :is() or :where()? Justify your choice and describe how you'd structure the CSS architecture.
2
In a large codebase with 50+ components, you notice inconsistent styling behavior when switching between :is() and :where(). How would you audit and standardize their usage across teams?
3
You're optimizing a legacy UI for performance and reducing CSS bundle size. How might replacing :is() with :where() in certain contexts improve maintainability or reduce specificity conflicts?

8+ years experience

1
You're leading a migration from a legacy CSS framework to a modern one that heavily uses :is() and :where(). How would you design a strategy to audit, document, and enforce correct usage across 10+ engineering teams without breaking existing UIs?
2
Your company is building a multi-tenant SaaS platform where each tenant can inject custom CSS. How would you architect the core UI library to use :is() and :where() in a way that prevents tenant styles from accidentally overriding system styles — or vice versa?
3
You're evaluating whether to standardize on :where() for all global utility classes across the organization. What are the long-term maintenance, debugging, and onboarding tradeoffs you'd present to the engineering leadership?

Follow-up Questions

❓What happens if you nest :is() inside another :is()?
❓How would you debug a style not applying because of unexpected specificity?
❓Can you use :where() to override a class-based style?